Nit: Suggest to use aiopsLogPatternsColumnsButton.

Updated in 5165088

Suggest to break that out and use EUI theme vars, something like:

import { css } from '@emotion/react';
import { useEuiTheme } from '@elastic/eui';

export const ExpandedRow: FC<ExpandedRowProps> = ({ category }) => {
    const { euiTheme } = useEuiTheme();

    const cssExpandedRow = css({
        marginRight: euiTheme.size.xxl, // =40px
        width: '100%'
  });

  return (
    <div css={cssExpandedRow}>
...

We use a similar pattern in x-pack/plugins/aiops/public/components/mini_histogram/mini_histogram.tsx.

Updated in 5165088

I'd like to suggest that we try to avoid relying on snapshot testing for new unit tests. A while ago we also documented old tests that we wanted to refactor and no longer rely on snapshot tests (#153288). The snapshots render the component with its props but do not assert what's actually rendered.

An alternative with react-testing-lib would look something like:

import {render, screen} from '@testing-library/react';
import '@testing-library/jest-dom';

...

describe('Format category components', () => {
    it('renders FormattedPatternExamples correctly', async () => {
      render(<FormattedPatternExamples category={category} />);
      expect(screen.getByText(/some text we expect to be rendered/i)).toBeInTheDocument();
    });
    ...
});

You could also adapt this to assert just certain pattern elements you'd expect to be rendered within span elements for the custom highlighting.

All I'm really interested here is the number of elements created, as in, how the line has been split up.
My original version of this test did just that, I'd count the elements and ensure that the line had been split up correctly.
Then I noticed that I'd get the same result by using snapshot.
I can revert this to counting the elements. Shame I deleted the code.

I've updated the test in ff9785b
Reverting it back to a test to count the number of elements returned from createFormattedExample

Nit: This could be just return createFormattedExample;.

Updated in 5165088

What do you think about dropping the font-weight for the wildcard style? With equal weights given to the tokens and wildcards, visually the tokens don't stand out from the variable parts of the message for me.

This is with font-weight: 500 for example:

I'm happy to change stying here, but before I do I think it's worth discussing which parts of the text do we consider to be more important?
The tokens, i.e. the shared words in each example, or the wildcard matches, i.e. the text which differs in each example?
I think there is an argument that the varying parts of the examples are more (or equally) interesting to the user. They'd want to see why these examples are different to each other.

Yes good point. It was just an initial impression. I did think the tokens were more important as we're displaying patterns here, but highlighting the variable parts of the messages is also valuable. Happy to stick with this for now and see if there's any future feedback.

Nit: This could be wrapped in a useMemo so it returns the same instance on every call as long as isDarkTheme doesn't change.

Updated in c45c849

Nit: This function could be wrapped in useCallback() to avoid returning a new instance every time. Otherwise I think the useMemo in FormattedPatternExamples might not memoize as intended.

Updated in c45c849

Nit: This css could be broken out to a definition outside the component scope. AFAIK the benefit would be that internally this would then be treated as a css class instead of inline css on every element.

As far as I can tell from testing, this still creates the class which is shared between all rows.
I believe this is why we were encouraged to use inline css= rather than style= for jsx.